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SECTION 1. INTRODUCTION 


Background Information concerning satellite-aided Search and Rescue (SAR) 
can be found in references 1 and 2. Briefly, the baseline satellite-aided 
SAR Mission concept consists of two systems; (1) the local coverage 
bent-pipe system, and (2) the global coverage system. 

In the bent-pipe system. Emergency Locator Transmitter (ELT)/Emerqency 
Position Indicating Radio Beacon (EPIRB) transmissions on 121.5/243 and 
406 MHz are relayed to a Local User Terminal (LUT) in real-time whenever 
there is mutual spacecraft visibility by an ELT/EPIRB and LUT. Three 
LUT‘s can provide full coverage for the continental United States, 

Alaska, adjacent maritime regions, and large oortions of the Atlantic 
and Pacific Oceans. 

In the global coverage system, 406 MHz transmissions from a new generation 
of ELT/EPlRB's will be processed by the SAR instrument onbc.i d a TIROS 
spacecraft. This on-board processing will consist of reci^ving, detecting, 
identifying, and measuring the frequency of the 406 MHz ELT/EPIRB trans- 
missions. The processed data will be input to the Manipulated Information 
Rate Processor (MIRP), which will insert this data Global Area Coverage 
(GAC) frames for tape recording (see section 2.1). Note that this pro- 
cessed data is also downlinked in real-time to the LUT's, but only when 
there is mutual visibility. 

The SAR 406 MHz incident data thus recorded will provide full global 
coverage. These data will be dumped whenever the TIROS spacecraft is 
over one of its two ground stations. A functional organization within 
the SAR mission is required to receive this dumped data in order to use 
them to compute the position of ELT/EPIRB transmissions. The functional 
organization will be the U.S. SAR Mission Control Center (USMCC). 
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The United States and Canada will each have a Search and Rescue Mission 
Control Center (MCC). 

The primary functions of the United States (USMCC) are as follows: 

a. Receive and process 406 MHz stored data and forward the 
received data to the Canadian MCC (see section 2.1). 

b. Forward position locations based upon stored 406 MHz data 

to the appropriate Rescue Coordination Centers (RCC's) (see section 2.1). 

c. Receive ephemerls data from the National Oc.anqraphic and Atmospheric 
Administration (NOAA) and distribute them to the Canadian MCC, the 

U.S. Local User Terminals, and to any other country/agency requiring 
them (see section 2.2). 

d. Receive recorded TIROS Information Processor (TIP) data that Is 
relative to the SAR Instrument (see section 2.3). 

e. Serve as the single point of contact for communications to NOAA; 

In particular, provide and coordinate commands to be relayed by the 

4 TIROS-N Spacecraft Operations Control Center (SOCC) to the SAR 

Instrument (see section 2.4) and resolve schedule conflicts (see 
section 2.5). 

. f. Receive acquisition (of spacecraft sianal) schedules from NOAA, 

A 

and forward this information to Canada's MCC and the U.S. LUT's 
(see section 2.6). 

g. Collect a data base In order to evaluate the effectiveness of 

* satellite-aided Search and Rescue system (see section 2.7). 

h. Ensure uniform software development and other coordination among 
the U.S. LUT's, and coordination with Canada (see section 2.8). 
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1. Together with the Canddlan MCC, provide aeneral, and any 
other, coordination of the satellite aspects of satellite-aided 
Search and Rescue. 

The SAR Instrument will consist of a Canadian repeater and a French 

processor for which Canada and France, respectively, will evaluate 

health and trends. * ‘i: 

% 

Section 2 of this document examines MCC functions In greater detail. 

Section 3 Is a summary of the Interface requirements necessary to 
perform each function, whereas section 4 summarizes the Information 
requirements between the USMCC and each of Its Interfaces. Section 5 
discusses the physical requirements (I.e., location, manning, etc.) 
of the USMCC. 
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StCTION 2. MISSION CONTROL FUNCTIONS 




SECTION 2. mission CONTROL FUNCTIONS 


This section develops the Mission Control functions enumerated In Section 1. 
2.1 SAR INCI D ENT DAT A 

The SAR Instrument will output processed 406 MH^ SAR Incident data Into 
the TIROS GAC formatter at the rate of 1200 bits oer GAC frame. This 
results In a bit rate of 2400 bits/sec. (Note that the data-flow Is also 
sent to the Canadian repeater with a biphase level cedinq.) The GAC frame 
format Is given In figure 2-1. GAC data are tape recorded and dumped when 
the TIROS spacfwraft Is over a TIROS ground station. The dumped data are 
first transmitted to the TIROS SOCC In Sultland, Maryland. The data 
are then relayed to the National Environmental Satellite Services (NESS's) 
Data Processing and Services Subsystem (DPSS) In Sultland, Maryland, for 
processing. In this section, SAR Incident data refer to the 406 MHz 
tape recorded data. 

SAR Incident data will be formatted by the SAR processor Into data messages. 
Each of these messages consists of eight 24-b1t words oriqnatinq from a 
single Data Recovery Unit (DRU). The format for these messages Is given 
In figure 2-2. In the event of multiple data messages, the eight words 
of DRU I's data message may be Interleaved with the eight words of DRU 2's 
data message, etc. 

The SAR Instrument data requirements will utilize 120 of the 559 spare 
words Immediately following the 520 TIP data words In the GAC frame 
(see figure 2-1). The SAR data will begin with the first word following 
the TIP data, and all SAR data will be contiguous. The first SAR word In 
any GAC frame will be a 24-b1t TBD sync pattern. Thus, 1176 bits will be 
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* 24-bit sync word plus 49 24-bit data words 




Finure 2-1. GAC Frame Format 
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Figure 2-2. SAR Processor Data Message Format 
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available for 49 SAR processor 24>b1t words. Since a data message 
consists of eight 24-b1t words, It Is possible to have a data message 
split among two GAC frames. A data message can also be split among 
two GAC frames because there may be Interleaving of the words of 
different DRU’s when there are multiple data messages. 

All SAR Incident data will be Input Into GAC and none will go Into 
TIP. All SAR housekeeping/status data will go Into TIP and none wi-11 
go Into the SAR portion of the GAC frame. 

SAR Incident data will be stripped out of the MIRP format In the same 
sequence as generated (I.e., not reversed) and reformatted for trans- 
mis ‘‘.o*' to the USMCC. These data should he available for transmission 
the USMCC within twenty minutes after data Is received at Sultland. 

The SAR data will be formatted at OPSS Into NASCOM 1200-bit blocks 
(see figure 2-3). Further Information describing fields In the NASCOM 
blocks and the NASCOI’ protocol as utilised by OPSS Is found In reference 3. 
The SAR Instrument data will be Inserted Into the available 1072-bit 
data field of each NASCOM block, beginning with the first bit of the data 
field. In contiguous Incrcmenti of one SAR data word. (Each SAR data 
word Is 24 bits.) No SAR data word will be split among two NASCOM blocks. 
Thus, the data field of a NASCOM block will contain from 1 to 24 SAR 
data words. 

When no data are available for the data flow, "non-significant" all zero 
24-b1t words will be output from the SAR 406 processor. OPSS will there- 
fore only put non-zero data words Into NASCOM blocks for transmission to 
the USMCC. 

The Doppler differences In the SAR Incident data will only yield the 
distance from the spacecraft to the ELT/EPIRB. In order to determine 
the position of the ELT/EPIRB, the time that the SAR Instrument received 
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Figure 2-3. Basic NASCOfI Block Format 
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the transmission is required because the spacecraft ephemeris is a function 
of time. Time is required to be accurate to at leaset 0.1 sec, which 
represents about 740 meters of the spacecraft's orbit. Time must either 
be input into the SA>R data messages or furnished by some other means, 
such as the following possibility: referring to figure 2-1, it is seen 

that each GAC fran« contains a four-word (40 bits) time code referenced 
to the first bit of data in the GAC frame. If this time code can be in- 
terpolated to each SAR data message within the 0.1 sec accuracy constraint, 
then it would not be required to insert time into the SAR inci-^ent messages 
itself. Note that there is a time code in the processor data message 
(see figure 2-2). This time code is a time counter which resets to zero 
about every 2‘i hours. (A 5-hour count is actually available if one 
considers the most significant bit of the time code, which is in TIP.) 

It is possible that future 406 processors will have their own 2.4 kbps 
clock and 0.5 second frame pulse which will constitute a spare in case 
of MIRP failure. 

Since, at most, 30% of the 406 data will be non-zero (probably 10% is a 
better r’timate), it is felt that a 7.2 kbps line will be adequate. 

This must be a full-dupljx line because of the acknowledgement protocols 
required for block transmission. SAR data will be output to the DPSS/USMCC 
modem at a rate consistent with the 7.2 kbps rate minus the NASCOM block 
overhead. 

SAR incident data will be retained until successful receipt at the USMCC. 

The SAR data of a given orbit will be transmitted to the USMCC in a time 
incrementing fashion. If there are data for more than one orbit to be 
sent the USMCC, then the data from the latest orbit will be transmitted 
first. 

The USMCC will use the dumped incident data to calculate the location of 
distress signals. Upon doing so, it will notify the appropriate RCC or 
agency (via teletype). Note that the LUT's have no use for the dumped data. 
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Canada also requires the dumped incident data for position location. 
The Canadian MCC will receive these data directly from the USMCC. 

2 . 2 EPHEMERIS DATA 

Ephemeri*’ data for the TIROS-N spacecraft is required by the LUT's in 
order to (1) compute the location of the repeated ELT/EPIRB signals, 
and (2) point the antenna. Ephetneris requir‘*ments for the latter 
function are much less stringent than for the former. Ephemeris data 
is also required for the position location algorithms associated with 
the 406 processed tape recorded (and dumped) data. 

In order to maximize the position location accuracy, the required 
ephemeris should bo as accurate as possible. The minimum accuracy re- 
quirement over three days is; 

3 kilometers along-track error 

300 meters radial error 

500 meters cross track error. 

Ephemeris data will be in earth fixed coordinates and consist of the 


following: 


X, Y, Z 

position 

• >- 

• X 

velocity 

T 

time 

The quantities X, 

• • • 

Y, Z, X, Y, Z, and T are double precision (64-bit) quantities 


It is assumed that ephemeris data will be transmitted once per day from 
NOAA's DPSS to the USMCC. From there it will be sent to Canada. (The 
initial orbital elements are supplied to NOAA by NORAD.) The ephemeris 
which is transmitted each day will consist of three day's worth of pre- 
dicted ephemeris expressed as minute vectors, i.e., 3 days x 24 hr/day 


H 
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X 60 min/hr » 4320 vectors (Includinq time and other TBO parameters). 

The position location software interpolates the cpheineris to the exact 
time required. 

The 3 kilometer along-track error previously mentioned represents the 
worse case after three days. The decay of predicted ephemeris accuracy 
is non-linear, with the rate of error increasing with time. The first •,* 

few minute vectors of the transmitted ephemeris data will have an 
along-track error of about 300 meters, and it is assumed that the first 
days of the predicted ephemeris will have an along-track error of 1 kilometer 
at most. Thus, if NOAA transmits ephemeris data once per day, the SAR 
mission will always have an ephemeris with an alonq-track error of 1 kilom- 
eter at most. 

If NOAA is unable to supply an ephemeris with the accuracy required by 
the SAR mission, then there are two options available: (1) the SAR 

mission could obtain the NORAD orbital elenients and propagate its own 
ephemeris; and (2) the SAR mission could update the NOAA-suppl ied 
ephemeris by using fixed earth beacons transmitting at 406 MHz. 

Ephemeris data will be transmitted from DPSS to the USMCC in NASCOM 
blocks over the same 7.2 kbps full duplex line that is required for 
transmitting SAR incident (section 2.1) and SAR instrument telemetry 
(section 2.3) data. Since the USMCC will compute position locations 
for the 406 processed tape recorded data, it will require all the 

•k * 

ephemeris because it is not known a oriori where an incident occurred. 

On the other hand, since the LUT's have a real-time mode of operation, 
they require ephemeris data for only thosa times that they are in the 
spacecraft's field of view. Therefore, USMCC will transmit to the LUT's 
only the ephemeris that they need. Since this represents about 60 minutes' 
worth of ephemeris data per spacecraft per LUT per day, transmission via 
teletype or another commercial line should prove adequate. 
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Since the Canadians are processinq recorded SAR incident data, they also 
require all ephemeris data. All epheineris data received by the U.S. 

MCC will be forwarded to Canada. 

2 • 3 SAR instrument HOUSEKEEPING/STATUS DATA 

The SAR on-board instrument, which consists of a Canadian repeater and 
a French 406 Processor, will input housekeepinq/status telemetry data into 
TIP. There are 104 eight-bit words in a TIP minor frame (see figure 2-4). 
There are 320 minor frames in a major frame and there is a new minor 
frame each 0.1 sec. SAR instrument housekeepinq/status telemetry is 
dispersed in the stored TIP data frame in v/ords 4, 5, 8, 9, 10, 11, 12, 
and 13. Upon receiving an analysis from NOAA, the SAR mission will determine 
which of the following options will be selected to send SAR instrument 
housekeeping data to the USMCC: 

a. O ption 1. For each TIP frame that is in GAC (see figure 2-1), 
all words 4, 5, 8, 9, 10, 11, 12, and 13 are stripped, reformatted, 
and sent to the USMCC. 

h. Option 2 . Only the particular words from each TIP/GAC frame 
which contain SAR instrument housekeeping data and TBD spacecraft 
parameters that are required for health and trends, are stripped, 
reformatted, and sent to the USMCC. The SAR instrument telemetry 
distribution in TIP is TBD. 

c. O ption 3 . Only the particular bits from each TIP/GAC frame 
which are SAR instrument housekeeping or required TBD spacecraft 
parameters are stripped, reformatted, and sent to the USMCC. 

The total SAR instrument, i.e., the Canadian repeater and French pro- 
cessor, requirements are estimated as 45 Dig B and 45 analog telemetry points. 


1-bit CV Status 


2-bit TIP Status 
I— 3-bit Major Franc Counter 


Minor Frame Period -0.1 sec 
Major Frame Period - 32 sec 
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Number is upper left-hand corner indicates Minor Frame word number. 

Time Code Data will appear during Minor Frame "0“ word locations 8 through 12. 

Char A is first byte of 24-bit word. Each byte is aligned such that three 24-bit words appear/frame 
*The subcommutation function is accomplished in the XSU. 


Figure 2-4. TIP Orbital Mode Minor Frame Format 
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When the TIROS spacecraft is over a TIROS ground station, real-time down- 
linked TIP data (about 10 minutes' worth) will be deconwiutated, limit 
checked, and monitored at SOCC for spacecraft health and safety use, and 
instrument health, safety, and command verification. No SAP. telemetry 
in real-time TIP is required to be sent to the USMCC. 

The SOCC will immediately notify the USMCC of out-of-limit conditions 
and non-verification of commands. This notification will be via teletype 
with telephone coordination. Canada's MCC will also be in this loop. 

The limit range (high fail and low fail) and the command verification bits 
will be supplied to the SOCC by the SAR project. 

The TIP word and frame rate is directly compatible with the GAC word and 
frame rate; five TIP minor frames are inserted (at 0.1 sec per minor frame) 
into the GAC frame each 0.5 sec (see figure 2-1). Two parity bits are 
added to the 8-bit TIP word to form the 10-bit MIRP word. All of the 
TIP, including the TIP that is downlinked in real-time is recorded in 
the GAC. Therefore, for complete instrument trend analysis, the SAR 
telemetry in TIP which becomes part of the GAC frame is required. Since 
Canada's MCC will be doing repeater trend analysis, it will receive 
housekeeping data from the USMCC. The Canadian MCC requires that these 
data be made available to it within two hours after they are downlinked. 

The mechanism for forwarding housekeeping data to the French for processor 
health and trend analysis is TBD. 

2.4 COMMANDS 

The SAR instrument command requirements are: 

Canadian Repeater 6 pulse discrete and 36 level discrete cotimands 

French Processor 12 pulse discrete commands 

INSTRUMENT TOTAL 18 pulse discrete + 36 level discrete = 54 commands 
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All commands and command lists will be resident In SOCC, which will 
receive conmand requests only from the USMCC. These command requests 
will be sent via teletype with telephone coordination; requests will be 
referenced to the command list resident In SOCC by acronym and/or 
nuiier.’cs. 

Command sequences will be compiled using Information furnished by the 
Canadian MCC, the LUT's ;*nd Fraice. Conmand sequences will be trans- 
mitted to SOCC only after close teletype/telephone coordination between 
the USMCC and Canadian MCC. One command sequence of about ten conmands 
per day transmitted one day In advance Is the estimated command re- 
quirement during a spacecraft’s activation phase; the operational phase 
Is anticipated to require one command sequence of 20 commands per week/ 
spacecraft. There are no critical commands that affect the health and 
safety of the spacecraft and no real time commands are anticipated except 
for a possible emergency. A safe condition command sequence will be 
supplied to SOCC. 

As stated In section 2.3, the SOCC will decommutate, limit check, and 
monitor TIP data for command verification. The USMCC will be immediately 
notified by SOCC of any failed condition, and the USMCC, In turn, will 
Immediately notify and consult with Canada. 

2. 5 SCHEDU LES A ND SCHEDULE CONFLICTS 

Any schedule conflicts and readjustments, e.g., due to emergencies, con- 
flicts within SOCC or DPSS schedulers, rescheduling due to line outages, 
etc., will be interactively resolved via teletype/telephone with the USMCC, 
which will be the single point of communications to NOAA for normal 
operations. 
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2.6 ACQUISITIO N SCHEDULES 

Since DPSS will have schedules of when the TIROS-N spacecraft Is within 
the Field of View (FOV) of the TIROS-N ground station, the USMCC and 
Canada’s MCC will want these sciiedules from DPSS so that they will know 
when to expect data. Assuming the existence of a 7.2 kbps line between 
DPSS and the USMCC, the acquisition schedules should be sent over this 
line, since there does not appear to be a requirement for a USMCC/DPSS 
teletype link. Note that, alternatively, the USMCC can derive these 
schedules from the ephemeris. 

Additionally, since the USMCC will only distribute to the LUT's the 
ephemeris that they need, the USMCC must know when TIROS is in the 
FOV of the LUT's. These acquisition schedules could be furnished by 
DPSS or derived by the USMCC from the ephemeris. 

2 . 7 SYSTEM EV AL UAH ON 

Efforts should soon begin to establish parameters to be used to evaluate 
the satellite-aided concept. A data base concerning present operations 
should be accumulated so that by 1981 there will be sufficient data by 
which to compare the impact of satellite-aided Search and Rescue. 

Parameters to be included in this data base may include the following: 

a. Category (aircraft, pleasure boat, etc.). 

b. Type of incident. 

c. Time elapse between distress and time reported (awareness stage). 

d. Time elapse between detection and planning (initial actions state). 

e. Time required for planning stage. 

f. Time elapse between SRU underway and rescue complete (or mission 
closed), i.e., operational phase. 

g. Time required for mission conclusion. 

h. If aircraft, was flight plan filed? If so, what type? 




1. Geographic data. 



(1) 

Terrain. 


(2) 

Country. 


(3) 

State. 


(4) 

Subregion 

J. 

Last 

known coordinates. 

k. 

Light and climate conditions. 

1. 

Locating agency. 

m. 

Distressed personnel data. 


(1) 

Number Involved. 


(2) 

Number located. 


(3) 

Total recovered/assisted. 


(4) 

Numbers recovered Injured. 


(5) 

Died enroute. 


(6) 

Total number dead. 


(7) 

Total number missing. 


(8) 

Total number saved. 


n. Exact coordinates of recovery/wreckage. 

0. Methods of detections of final location. 

p. Resources used. 

(1) Personnel. 

(a) Civilian. 

(b) Government. 

(c) Time expended. 

(2) Number and type of aircraft used. 

(3) Number and type of aircraft lost. 

(4) Hardware/suppl les used. 

q. Was ELT/EPIRB Involved? 

(1) Was awareness of distress by ELT/EPIRB? 

(2) Was ELT/EPIRB helpful In final location? 

(3) Was ELT/EPIRB operational during distress? 
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r. Quantitative ELT/EPRIB Information. 

(1) Number of ELT/EPIRB Incidents. 

(2) Humber of •Veal" ELT/EPIRB Incidents, l.e., relating to a 
distress condition. 

In the United States, the primary agencies for gathering this type of 
Information are the U.S. Air Force and U.S. Coast Guard. It Is assumed 
that these agencies, as well as the Canadian MCC, will add to and modify 
the preceding list, they will also begin to compile a data base of the 
data In the list that Is relevant to their respective Search and Rescue 
charters. 

2 . 8 LUT COO RD I NAT 1 ON 

It Is a design goal that the LUT's be almost Identical and be self-sufficient. 
During the Demonstration Phase, however, the LUT's will be manned, and there 
will be coordination between them and with the MCC's. 

There Is differing opinion on how much the LUT's will have to be programmed 
when the SAR Instrument Is first launched. The amount of such reprogranining 
will strongly depend on the amount of system simulation there will be before 
launch. If the system Is properly exercised before launch, the amount of 
reprogramming will be minimal. In any case. In order to ensure uniformity 
of software In the LUT's, the Mcc's will assume the coordination responsi- 
bility for software updates. 

As a system "self-test", the MCC's can compare their position locations of 
406 MHz ELT/EPIRB's with those obtained by the LUT's. Note that when 
there Is mutual spacecraft visibility by an ELT/EPIRB and LUT, the pro- 
cessed 406 data will be downlinked to the LUT as well as tape recorded. 

Note also that there will be cases when tape recorders will provide 406 
position location faster than the bent-pipe system. This can happen, for 
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example, on an overflight where each of two LUT's receives less than 
three minutes of bent-pipe 406 data and, therefore, neither has enougn 
information to calculate position. 

2 . 9 MISSION CpOROJ NA T I ON 

All coordination of satellite-aided Search and Rescue will be the joint 
responsibility of the U.S. and Canadian MCC's. 
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SECTION 3. 


MISSION CONTROL FUNCTION REQUIREMENTS 


This section Is a summary of the Interface requirements necessary to per- 
form the mission control functions. These requirements are given In 
table 3-1. Figure 3-1 gives an overview of the SAR mission data flow. 
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Table 3-1. U.S. SAP Mission Control Center Functions Th#»ir fiata Requirciie^ts 


FUNCTION 

REFFREfICE 

INTERFACE 

1 

COPMUNICATIONS llNA 

Receive and {.rocess 406 Wz stored data 

Section 2.1 

NOAA/OPSS ♦ usncc 

7.2 kbps full duplei 


1 

USMCC Canada MCC 

!TB0 

Forward position locations based upon stored 406 HHz 
data to appropriate RCC*s 

Section 2.1 

1 

( 

i 

USfXC RCC's : Tel et]fpe/ telephone 

USMCC-^ Canada MCC (for self test) Tele type/ telephone 



USMCC-^ lUT‘s (self test and 
data base) 

Te 1 e type/ tel ephone 

Receive and distribute ephemeris data 

Section 2.2 

NOAA/DPSS ♦ JSWCC 

7.2 kbps full duplex 



usncc ^ Canada NCC 
USMCC - CUT’S 

TED 

Teletype or other commercial 

Receive recorded TIP data relative to ♦he SAR ! 

instrument 

Section 2.3 

NOAA/OPSS - usncc 
nOAA/J^S ^ Canada HCC 
or 

usncc ^ Canada nCC 
T9*) ♦ France 
UyiCC-- Canada nCC 
USTICC— Lurs 

usncc socc 
irsncc - rpss 

7.2 kbps full dupU*. 

Single point of contact for cormuni cat ions to NOAA 
(commands, emergencies, resolution of schedule 
conflicts, etc.) 

Section 2.4 
Section 2.5 

TBO 

TBO 

T e 1 e t ype / 1 e 1 e phone 
T e 1 e t ype / t e 1 e phone 
Te 1 e type/ te 1 ephone 
Te 1 e type/ te 1 t phone 

Receive and forward acquisition schedules 

Section 2.6 

NOAA/DPSS ♦ USftC (or c«n 

got from ephemeris) 

USMCC - LUT’s 

USMCC -> CaiMda NCC (if desired) 

7.2 kbps full duplet 

teletype 

Teletype 

* 

1 

m • * 
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Table 3-1. U.S. SAR Mission Control Center Functions and their Data Requirements (cent.) 


FUNCTION 

1 

reference 

INTERFACE 

1 

1 COPflUNI CAT ions LIIK 

Collect data bas«. for system evaluation 

Section 2.7 

USHCC>-> Canada MCC 

< 

Telephone 



Canada nCC<-« ONO 

Telepx>ne 


1 

US»CC-» 'I.S. Coast Guard 

Telephone 


1 

1 

USKCC— U.S. Air Force 

Telephone 

Coordination among LUT*s(e.g. . software development) 

i 

Section 2.8 

USMCC-- Canada HCC 

Tel etype/ telephone 



USMCC-- LUT*s 

Tel e type/ te 1 ephone 

General coordination of satel'ii te-aided Search and 
Rescue 

1 

Section 2.9 

1 ( 

' 1 

USMCC— Canada MCC 

1 

1 

1 

Te 1 e t ype/ te 1 ephone 

1 
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OISTRIB. OF EPHEMERIS ANO 
tOORD. OF U.S. LOT'S 


CfOS TO S/C 

HOUSEKEEPINr, 

T/N DATA HOalTOA 


Figure 3-1. SAR Mission Data Fltm^for Noma) Operations 
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SECTION 4. MISSION CONTROL INTERFACE REQUIREMENTS 


A summary of the functional data requirements between the U.S. Mission 
Control Center and each of its interfaces is given in table 4-1. 


Table 4-1. Mission Control Interface Requirements 


r. 

»- 

% 


INTERFACE 

DATA DESCRIPTION 

DATA FLOW * 

NOAA/DPSS 

SAR incident data stripped from GAC 

4 - 


Ephemeris data 

4 - 


Instrument TIP telemetry data 

4 - 


Acquisition schedules 

4 - 


Schedules and schedule conflicts 

4 -^ 

NOAA/SOCC 

Instrument commands 

-> 


Emergencies 



Schedules and schedule conflicts 

4 — ► 

RCC's 

Position location 

>> 


Data base information 

4 - 

LUT's 

Ephemeris 



Acquisition schedules 



Position locations (for data base) 

4 -4 


Software update uniformity 

4-4 

U.S. Coast Guard 

[ Coordination and data base 

4-4 

U.S. Air Force 

Coordination and data base 

4-4 

Canadian MCC 

All coordination 

4-4 


Ephemeris data 

-4 


SAR incident data stripped from GAC 

-4 


Instrument TIP telemetry data 

-4 


Acquisition Schedules 

-4 


Data base 

4-4 


* An arrow pointing to the rioht denotes data flow from the USMCC; an arrow to 
the left, data flow to the USMCC. 
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SECTION 5. U.S. MISSION CONTROL CENTER 
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This section suggests possible alternatives for locating the U.S. Mission 
Control Center in the SAR system. In broad terms, the USMCC is responsible 
for: (1) distributing information (ephemeris, 406 MHz stored data, and 

SAR instrument TIP data); (2) calculating distress positions based upon 
stored 406 MHz data; (3) serving as the single point of contact for coninuni- 
cations to NOAA; and (4) coordinating, with Canada, the satellite-aided SAR 
mission. Note that the first two broad functions require a computing facility. 
Additional USMCC functions that require a computing facility include the 
following: strip/fonnat telemetry data, assembly of a SAR mission data base, 

ephemeris processing, spacecraft and LUT scheduling, Jisplay/console support, 
and reporting formats. These computing functions are baselined for two con- 
currently operational SAR instruments. 

An appealing solution for the USMCC could be to colocate it with an LUT. 

This has the important advantage that the USMCC could use an LUT's 
computing facility. The net result would be that the USMCC could be 
manned by a single person with a teletype and telephone. It is assumed 
that the manning would be a joint U.S. Air Force/Coast Guard responsibility. 

In order for the USMCC to share an LUT's computing facility, the SAR mission 
would require that the facility not be overloaded and that the LUT's 
operations not be impacted. To assure these conditions, the LUT in question 
would be provided with a more powerful computing facility than the other 
LUT's. This is feasible only when all LUT's will be provided with members 
of a compatible computer family. The reason for this is the requirement 
for software compatibility. 
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Another alternative would be for the U.S. Mission Control Center room to 
be colocated with one of the large RCC's (such as Scott AFB or Governors 
Island) and for the USMCC to use a large existing Air Force or Coast Guard 
computing facility. The cost effectiveness of this alternative should be * 
carefully studied and weighed against some of the disadvantages. One 
disadvantage is that the large computer facilities are not normally geared 

4 * 

to a "real-time" mode for operation. The computing facility would have to < 
accept 406 data when available, expeditiously compute locations, transfer 
406 data inmediately to Canada, transfer instrument TIP data to Canada 
within two hours, etc. SAR entry into the computing facility would be by 
remote control. Another disadvantage is an interface problem. Would 
data go from Suitland directly to the computing facility or would it go 
from Suitland to the USMCC, and from there be switched to the computing 
facil ity? 

The final alternative would be for the USMCC to have its own computing 
facility. If this were the case, then that computer should be compatible 
with the LUT computers in order to use the position location software 
developed for the LUT's. 

In sunmary, there are viable alternatives for locating the USMCC, but 
further explorations between the SAR project, the Air Force, and the 
Coast Guard are needed. 
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GLOSSARY 


CRC 

OND 

DPSS 

DRU 

ELT 

EPIRB 

GAC 

LUT 

MCC 

MIRP 

NESS 

NOAA 

RCC 

SAR 

SOCC 

SRU 

TIP 

USMCC 


Communications Research Center (Ottawa, Canada) 
Department o^ National Defense (Canada) 

Data Processing and Services Subsystem • 

Data Recovery Unit 

Emergency Locator Transmitter 

Emergency Position Indicating Radio Beacon 

Global Area Coverage 

Local User Terminal 

Mission Control Center 

Manipulated Information Rate Processor 

National Environmental Satellite Service 

National Oceanic and Atmospheric Administration 

Rescue Coordination Center 

Search and Rescue 

Spacecraft Operations Control Center 
Search and Rescue Unit 
TIROS Information Processor 
United States MCC (for Search and Rescue) 
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